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Abstract. Nowadays cartography and Geographic Information Systems 
(GIS) are becoming more and more intertwined with custom software de- 
velopment as for example in Web GIS applications. In this context, this pa- 
per raises some concerns that go towards programmer-friendly access of 
spatial data in the realm of cartography. We argue that there is an object- 
relational impedance mismatch between the traditional cartographic work- 
flow, where relations are used to store/ access spatial data and the object- 
oriented software development. Therefore, this research promotes integrat- 
ed cartographic and programmatic application development based upon the 
concept of using object-orientation for overall handling of geospatial data 
access and vi sual i zati on over the Web. 
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1. Introduction 

The development of innovative cartographic and Web-based Geographic 
Information Systems (Web GIS) applications for visualizing spatial data 
over the Web often i mpl ies custom software i implementation. Furthermore, 
in some cases the efficient and programmer-friendly access and handling of 
spatial data can become equally important to visualization, mainly due to 
the importance of software development during the overall implementation 
of such mappi ng appl i cati ons. 

We first investigated this issue in (losifescu 2009) and then mentioned it in 
connection with service-driven cartography and service- oriented architec- 
tures (SOA) for Web-based mapping applications in (losifescu 201]). More 
recently, we had the opportunity to encounter similar issues in the field of 
cartography for environmental sciences, more specifically in the frame of 



the projects SwissExperiment and OSPER (Open Support Platform for En- 
vironmental Research). 

The main goal of these environmental projects has been to enable effective 
real-time environmental monitoring through a common, modern and ge- 
neric cyber- infrastructure. This goal was effectively implemented through 
the development and provision of a platform for large-scale sensor network 
deployment and information retrieval and exploitation (losifescu et al. 
20 10, SwissExperiment 20 B). 

The SwissExperiment/ OSPER Platform is an open support platform for 
worldwide environmental research experiments, which is designed, imple- 
mented and supported by Swiss research institutes (SwissExperiment 
2013), at the initiative of the Competence Centre Environment and Sustain- 
ability of the ETH Domain (CCES). From the technical point of view, the 
platform contains mainly three interoperable components: (1) a data docu- 
mentation system, (2) a management system for sensor data and (3) a ser- 
vice-driven Web-GI S platform. The data documentation system is the Swis- 
sExperiment Wiki 1 . It is organized as a semantically enhanced metadata 
store based on the Semantic MediaWiki 2 and it is being developed by the 
WSL Institute for Snow and Avalanche Research (SLF). The data manage- 
ment system for sensor data is the Global Sensor Networks (GSN) 3 . GSN is 
aj ava-based open source middleware designed to facilitate the deployment 
and programming of sensor networks and it is being implemented by the 
EcolePolytechniqueFederalede Lausanne (EPFL). The third component of 
the SwissExperiment infrastructure, namely the Gl S Platform for I nterdis- 
ciplinary Environmental Research, serves for the discovery, visualization 
and download of sensor and spatial data through a service-driven architec- 
ture (losifescu et al. 2010). This Web-GIS platform is based on GeoVITe 4 
framework and is being developed at ETH Zurich. The GIS Platform for 
Interdisciplinary Environmental Research is the main cartographic visuali- 
zation system for the presentation of sensor data (I osifescu et al. 2010) and 
recently it uses an additional caching mechanism written in thej ava pro- 
gramming language that regularly retrieves and stores the latest sensor 
measurements in order to improve the performance of the cartographic 
display. 



1 http://www.swiss-experiment.ch/index.php/SwissExWiki:Home, accessed 20 March 2013 

2 https://www.semantic-mediawiki.org/, accessed 20 March 2013 

3 http://sourceforge.net/apps/trac/gsn/, accessed 20 March 2013 

4 https://geodata.ethz.ch/gis/, accessed 20 March 2013 



TheSwissExperiment/OSPER platform integrates highly flexible and loose- 
ly-coupled components in an interoperable system. As a requirement for 
interoperability, the sensor measurements are transferred from one com- 
ponent to the other using serialization mechanisms and standardized for- 
mats such as web services and GML (Geographic Markup Language). How- 
ever, in the SwissExperiment/OSPER platform there are three specific use 
cases where i ntegrated cartographic and programmatic access would make 
sense: (1) developers would I ike to integrate the sensor data displayed in the 
Web GIS directly as objects in an object-oriented programming language 
such as J ava for further processing, (2) the developers would like to save 
the serialization and deserialization overhead associated with data transfers 
among the platform components programmed in J ava and (3) automatic 
synchronization between the J ava software handling caching of recent sen- 
sor data and the relational database used by the Web Gl S in order to display 
this data. These specific use cases and similar use cases as presented in pre- 
vious work (losifescu 2009, losifescu 201]), emerge when cartographic 
presentation in a Web GIS is intertwined with additional data processing 
implemented in a programming environment. 



2. The Object-Relational Impedance Mismatch for 
Spatial Data 

The premise of this research is that current handling of geospatial data 
based on relational concepts can become cumbersome in the current pro- 
gramming environment where object-orientation is the norm for software 
development. We will emphasize, for spatial data, the impedance mismatch 
between existing relational concepts and the object-oriented software de- 
velopment, which is visible in the complicated development process of new 
mapping applications and the lack of compile- safety when accessing spatial 
data. 

Existing geospatial systems enforces the notion of a layer for geographic 
data. A layer is a collection of data with a common type or theme as for ex- 
ample cities, rivers, streets or buildings. In the relational model all spatial 
features of the same category are managed together within the same sche- 
ma/table, and each record in the table corresponds to a spatial feature. 

As a consequence, when working with spatial data objects in an object- 
oriented programming language such as J ava, we encounter two main chal- 
lenges. First, many conversion steps are necessary for accessing the data 
and mapping it to objects in a programming language. The second disad- 
vantage is the lack of compile- safety, which may cause errors that are only 
discovered at run-time. For example, database programming requires pos- 



sibly lengthy SQL (Structured Query Language) queries that contain the 
col umn names as si mpl e stri ngs. As the compi I er i s not abl e to i nterpret the 
meaning of these strings, some small typing mistakes may cause errors at 
run-time. 

When consi deri ng the conversi on steps necessary for accessi ng the data and 
mapping it to objects in a programming language, one might argue that 
there are many third- party libraries that offer useful functionality to allevi- 
ate this problem. It is true that the overhead required to read popular GIS 
data formats and to execute SQL queries from spatial databases is greatly 
reduced by the use of libraries such as GeoTools 5 . However, when dealing 
with non-standard geospatial data such as sensor data managed by GSN, 
the implementation still requires a deserialization of theGML format used 
for data transfer, or in other words a conversion from the features serialized 
in GM L according to a relational model to generic features stored in a data 
structure supported by the library. An additional conversion is required to 
transform these resulting data structures into application-specific spatial 
objects that can be suitably used to implement the application logic. Moreo- 
ver, these conversions must take pi ace every time when the software access- 
es certain data. I n computer science terms these kind of conversions that 
occur repeatedly, are named recurring mappings. Figure 1 depicts the prob- 
lem of recurring mappings that usually occur in software dealing with spa- 
tial dataflosifescu 2009). 
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Figure 1 Overview of recurring mappings: first from GML relational fea- 
tures to a data structure accessible from within the code - relational to ge- 
neric features - and a second one from the resulted data structure to spatial 
objects that can be suitably used in the application logic - generic to appli- 
cation specific - (losifescu 2009). 



5 http://geotools.org/, accessed 20 March 2013 



3. Object-Oriented Databases as a Solution to the Ob- 
ject-Relational Impedance Mismatch for Spatial Da- 
ta in a Web-GIS 

On one hand, in order to fulfill its cartographic role a traditional Web-GIS 
needs access to existing spatial data, which is normally available in rela- 
tional form. The relational storage of spatial data is a constraint given by 
the existing GIS and cartographic tools, as well as by standardized formats 
defined for spatial data exchange (e.g. GML) which expect geographic data 
to be modeled in this manner. For example, the main cartographic mecha- 
nism of the Web-GIS application (which will be presented Section 4) and of 
the GIS Platform for Environmental Research is following a service- driven 
architecture based on the QGIS mapserver (losifescu et al. 2010). QGIS 
mapserver 6 is implemented in theC-H- programming language and it is able 
to access popular geographic data sources such as PostGIS 7 databases, 
which follow a relational model. 

On the other hand, a programmer needs access to objects in the specific 
programmi ng I anguage bei ng used for the devel opment of appl i cati on I ogi c. 
I n the specific case of the caching mechanism developed for the GIS Plat- 
form for Environmental Research of the SwissExperiment/OSPER project, 
the application logic was programmed in J ava. Therefore, the generic solu- 
tion was to use an object-oriented database management system (ODBMS) 
that integrates and builds upon existing spatial database concepts (such as 
geometry data types, spatial functions, and spatial indexes) in an object- 
oriented manner. From a technical perspective, for this role we chose the 
native J ava version of the db4objects (db4o) by Versant 8 . It is an open 
source ODBMS that is marketed as a one-line-of-code database for J ava 
and .NET applications. There are many reasons for choosing db4o beyond 
its developer- friendliness. Among these, we mention our previous experi- 
ence in programming with db4o, its ability to work in server mode and its 
db4o Replication System 9 (which can be used to automatically replicate 
objects into a more traditional relational database). 

Furthermore, for the transition from a relational to an object-oriented 
model it is possible to define a mechanism for programmer-friendly devel- 



6 http://karlinapp.ethz.ch/qgis_wms/index.html, accessed 25 March 2013 

7 http:// postgis.net/ , accessed 25 M arch 2013 

8 http://www.db4o.com/, accessed 25 March 2013 

9 http://www.db4o.com/about/ productinformation/drs/, accessed 25 March 2013 



opment on top of the object-oriented database that can directly transform 
existing spatial features (which can be available for example in GML or a 
spatial database) in class definitions that can be stored in the object- 
oriented database. 

In addition, an import module handles the automatic transformation of 
spatial data into objects and an export module is generating a programmer- 
friendly Application Programming Interface (API) for accessing spatial da- 
ta. The input to the import module is a collection of generic spatial features 
and its output is a collection of spatial objects. The export module is gener- 
ating a lightweight computation component that provides access, from ex- 
ternal code, to the imported spatial objects managed by the ODBMS. The 
API contains the class definitions as well as the libraries controlling the 
communication and the transport of spatial objects with the application 
code. 

The final required module required for integrated cartographic and pro- 
grammatic access to spatial data is a synchronization module with a more 
traditional spatial Relational Database Management System (RDBMS). 
Even if the implementation of application logic requires an object-oriented 
way of dealing with spatial data, we often need to transform spatial objects 
back to traditional relational databases (such as a PostGIS database) since 
spatially enabled RDBMS are the norm in thegeospatial domain. Therefore, 
in order to enable interoperability and integration with existing geodata- 
bases and geospatial tools, we need the means to replicate and synchronize 
an object database (eg. db4o) with one or more external relational geoda- 
tabases (e.g. PostGI S). 

As previously mentioned, our Web-GIS application is based on a service- 
driven cartographic architecture (losifescu et al. 2010, losifescu 2011). In 
addition to a Graphical User Interface (GUI), service-driven cartography 
imposes a three-tier architecture comprising also a spatial database (eg. 
PostGI S) and a cartographic Web service (eg. QGI S mapserver) as an archi- 
tectural style for the development of Web cartographic applications 
(losifescu 2011). 

In the system illustrated in Figure 2, while the ODBMS is used for the pro- 
grammer-friendly access to spatial objects needed during the implementa- 
tion of application logic, the RDBMS is responsible for serving data for web 
map publishing. In an attempt to generalize, we believe that a RDBMS is 
necessary everywhere we need to be compatible with Spatial Data I nf re- 
structures (SDIs), whilean ODBMS can act as an additional cachefor exist- 
ing geodatabases and, through the synchronization module, it can be also 
i ntegrated i n wi der SDI s. 





API for geodata access web map publishing 



Figure 2. General design for integrated cartographic and programmatic 
access to spatial data in a Web-GI S (after I osifescu 2009). 



4. Applications of Integrated Cartographic and Pro- 
grammatic Access to Spatial Data 

4.1 . Proof-of-Concept Web-GIS 

The concept of integrated cartographic and programmatic access to spatial 
data can be first demonstrated with a generic Web-GI S application (I osifes- 
cu 2009), that allows the users to upload data, change the symbol ogy inter- 
actively and finally to access, edit and analyze the spatial data with a pro- 
grammer-friendly API designed for thej ava programming language. 

First of all, the proof-of-concept Web-GIS application allows the user to 
upload data in theShapefileformat. As illustrated in Figure 3, the checkbox 
that enables an integrated cartographic and programmatic access to the 
uploaded data in the Web-GI S is selected by default. After the upload, the 
system analyzes the uploaded data, automatically extracts its schema and 
based on this schema, it generates the corresponding J ava classes. These 
domain classes can be optionally enhanced with methods that define their 
domain and application specific behavior. Finally, based on the generated 
J ava classes, the system instantiates objects and sets the geometry and the 
attri butes as obj ect properties. 
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Figure 3. Shapefile upload in the generic Web-GIS for in an integrated 
cartographic and programmatic access (I osifescu 2009). 



The created objects are then added in an ODBMS, more specifically a db4o 
instance configured in server- mode. After the objects are inserted in the 
object-oriented database, a replication mechanism is triggered that syn- 
chronizes the db4o object-oriented database with an additional PostGIS 
relational database. 

As explained in Section 3, the additional storage of spatial data in a rela- 
tional spatial database is a constraint given by the existing cartographic 
tools. Since the generic Web-GIS is following a service-driven architecture 
(I osifescu 2011), the PostGIS database is used by the cartographic side of 
theWeb-GI S application in order access this data and create the map that is 
presented to the user. Furthermore, a user can access basic options for the 
configuration of symbol ogy as shown in Figure4 and as a consequence, the 
user has the possibility to interactively symbolize the uploaded data sets. 

Regarding the cartographic perspective, we can mention that the generic 
Web-GIS also has additional interactive functionalities such as map export 
as PDF and an adaptive interface for mobiledevices (I osifescu 2009). 




Figure 4. The cartographic si de of the generic Web-GI S (I osifescu 2009) . 



However, the main advantage of the integrated cartographic and program- 
matic approach is the efficient access to the data. From the programmatic 
side of the Web-GI S, developers can efficiently access the data. The access 
to data implies a simple download of a library (generated dynamically by 
the Web-GI S for the visualized datasets) and theinclusion of this library in 
a newj ava project. The developer can then use the API implemented by the 
GeoObjects class, shown in Figure 5, in order to programmatically access 
the data directly as objects. The access to spatial data is achievable with a 
few line of code: first the GeoObjects datastore is opened, then a prototype 
for the class of objects is instantiated and finally a query is performed that 
returns a col I ecti on of spati al obj ects that match the prototype as i 1 1 ustrated 
in Figure 5. From there on, the developer can use the retrieved objects for 
implementing the required application logic. 

The developer-friendly access to the spatial data uploaded in the generic 
Web-GI S is enhanced by the location transparency provided by the GeoOb- 
jects datastore. Therefore, the developers do not even have to configure 
I nternet Protocol (I P) addresses, nor they have to specifically know where 
the object-oriented database is located, since the included Web-GI S API 
automati cal I y i nd udes al I th i s i nf ormati on . 
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F igure 5. The programmati c si de of the generi c Web-GI S (I osifescu 2009) . 



4.2. Applications in the SwissExperiment/OSPER Project 

The object-oriented concepts and design were also applied for the develop- 
ment of the caching mechanism used in the cartographic presentation of 
sensor data for the SwissExperiment project. A J ava servlet regularly con- 
nects to the GSN i nstance that stores sensor data, requests the I atest sensor 
measurements i n GM L format, converts the recei ved data i nto vari ous types 
of sensor objects and then queries the db4o ODBMS for matching objects 
havi ng si mi I ar names. 

If the query returns a match, it means that the object (sensor) is already 
available in the db4o and its properties (sensor measurements) must only 
be updated with the newest values. If the query does not return a match, it 
means that we deal with a new sensor and then the new object is simply 
added to the db4o. Finally, thej ava servlet triggers the replication mecha- 
nism of the db4o server, which synchronizes the available sensor objects 
with the corresponding tables in a PostGIS RDBMS. From thePostGIS, the 
newest sensor data i s made avai I abl e to the Gl S PI atform for E nvi ronmental 
Research. 



I n the case of the OSPER project, it is planned to further use the i ntegrated 
cartographic and programmatic access to the sensor data in the cache in 
order to implement application logic that will detect sensor measurements 
anomalies. As soon as these anomalies are detected, they will be displayed 
in a planned sensor supervision center, which will become available as an 
additional layer in the GIS Platform. Due to the integrated cartographic and 
programmatic access to the sensor data implemented in the cache, the Gl S 
platform developers have immediate and full access to sensor objects and 
can therefore focus on application logic (creating the algorithms necessary 
to detect sensor measurements anomalies) instead of investing lots of effort 
for deal i ng with the basi c task of accessi ng spati al data. 



5. Influences of Object-Oriented Concepts in the 
Wider Context of Web Cartography 

The object-oriented concept for accessing spatial data can have additional 
influences beyond specific cartographic application development. In the 
wider context of Web Cartography, open standards and web services are 
currently the newest mechanisms enabling the dissemination of spatial in- 
formation in real-time over the Web. 

In service-driven cartography, Cartographic Web Services (CartoWS) use 
the OGC standard Symbol ogy Encoding (SEP for styling map data inde- 
pendent of any service interface specification. Furthermore, cartographic 
extensions for the SE standard allow expressing cartographic rules with 
advanced point symbol izati on, patterns for all spatial features, gradients, 
advanced features filtering and thematic mapping (losifescu et al. 2009, 
losifescu 2011). 

For fine-grained selection and symbolization of individual geometric fea- 
tures, CartoWS make heavy use of another OGC standard, namely the Filter 
Encoding Standard (FES) n . For example, based on constraints specified on 
values of spatial, temporal and scalar properties it is possible to identify a 
subset of features and render them with a particular predefi ned symbol ogy. 

In this context, a restriction of the relational model is visible in the compli- 
cated and lengthy Filter definitions that must be created in order to assign a 



m http://www.opengeospatial.org/standards/symbol/, accessed on 25 March 2013 
u http://www.opengeospatial.org/ standards/ filter/, accessed on 25 March 2013 



specific symbol ogy to an individual feature or to a sparse group of features. 
Filtering works top down, starting with all features in a layer, and gradually 
eliminating the features that do not fit the defined selection predicates until 
only the desired feature remains. While this approach is very suitable for 
the assignment of symbol ogy to entire layers, it is not well suited for indi- 
vidual features because of the significant effort required to define the predi- 
cates for the sel ecti on . 

With an object-oriented approach, filtering and selection may become un- 
necessary. Individual spatial objects could have, as part of their behavior, 
one or several symbol ogies assigned to them, as well as drawing order and 
possibly additional instructions on how to handle cartographic conflicts. 
Since the assignment of symbology is made to individual spatial features, 
the symbol izati on of entire layers can work bottom up. I n this manner, leav- 
ing aside any technical considerations regarding rendering performance, 
spatial objects could be programmed to draw themselves and a map created 
in this manner could have its content organize itself. 



6. Conclusions 

Our research identified that developers spend a lot of time with spatial data 
access instead of programming the application logic and that multiple error 
prone conversions are unavoidable when transferring data between the 
runtime domain objects and a relational vector data source. Due to the con- 
straints of the existing relational data model for storing geospatial data, in 
specific cases developers inadvertently have to deal with the object- 
relational impedance mismatch, which makes cartographic application de- 
vel opment I ess eff i ci ent and more error prone. 

With this research we have demonstrated that it is possible to achieve spa- 
tial data access and conversions in a completely transparent and object- 
oriented manner over the Web with an integrated cartographic and pro- 
grammatic mechanism, which is based on an object-oriented database. The 
most obvious advantage of an object-oriented spatial data handling is the 
reduction of the development time, as mappings and transformations are 
no longer necessary. 

Furthermore, the automatic replication of spatial objects to relational spa- 
tial databases proves the flexibility and the integration potential with exist- 
ing cartographic tools and technologies, while making the implementation 
of custom spatial data processing more programmer-friendly and more in- 
tegrated with the cartographic visualization. 



These i integrated cartographic and programmatic functionalities of the Web 
Gl S are possible because, on one hand, the map representation is separated 
from the Gl S data, and on the other hand, the relational spatial data is au- 
tomatically transformed in J ava objects for programmer-friendly develop- 
ment. 

Finally, we have presented several ideas about how object- orientation can 
further influence the cartographic realm and the future integrated map ap- 
pl i cati on devel opment for the I nternet. 
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